home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 26
/
Cream of the Crop 26.iso
/
os2
/
rexxgdb2.zip
/
ReadMe.1st
< prev
next >
Wrap
Text File
|
1997-08-10
|
11KB
|
248 lines
************************************************************************
REXXGDB2
Release Highlights, Tips, and Last-minute notes
************************************************************************
Version 1.30 Sunday, August 10th, 1997
========================================================================
1. Dynamically generate HTML-encoded files for Lists, Listboxes, Images,
Textarea, etc. from your SQL Select statements
2. Include descriptions and examples how to utilize RexxGDB2 from within
Goserve (Freeware Web Server for OS/2 Warp by Mike Cowlishaw,
IBM Fellow, IBM UK Laboratories)
3. Select Large Objects Into Files
4. Use resources more efficiently
5. Safer and more robust support of multi-threaded Rexx programs
running in multiple processes within the same (client) PC
Please read the updated REXXGDB2.INF for more details.
Examples of what this RexxGDB2 version is able to do:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. The following program is complete and executes only about one second.
It builds a complete table-encoded HTML file for your SQL query and
launches your browser to view it...
/* rexx */
call rxfuncadd 'g2loadfuncs', 'REXXGDB2', 'g2loadfuncs'
call g2loadfuncs
call g2connectshare 'SAMPLE'
call g2h 'www.htm', 1, '<FORM METHOD="POST">'
call g2hselect2table 'www.htm', 1, 'Select * from staff', 999
call g2h 'www.htm', 1, '</FORM>'
'netscape file:///www.htm'
return
2. We were able to run simultaneously and safely many multi-threaded
Rexx programs, each calling RexxGDB2 G2Select functions, in multiple
processes for numerous hours, including those running within PMRexx.
------------------------------------------------------------------------
Version 1.20 Sunday, November 17th, 1996
========================================================================
1. Intel 486-optimized
The new version is now optimized for Intel 486-class processors.
The functions still run on Intel 386, Pentium or newer processors.
2. G2GetToken is introduced to obtain a surrogate key (unique number)
from a table dedicated for keys.
Please read the updated REXXGDB2.INF for more details.
------------------------------------------------------------------------
Version 1.10 Sunday, August 11th, 1996
========================================================================
1. Multi-threaded support
The new version has been improved to work properly in a multi-
threaded REXX environment.
2. G2Immediate, G2SelectCols, G2SelectData, G2SelectForm, and
G2SelectOne can now receive a long SQL statement from REXX caller
programs. Please read the updated REXXGDB2.INF for more details.
3. G2SelectData, G2SelectForm, and G2SelectOne now correctly handle long
character columns (VARCHAR, LONG VARCHAR, etc.).
Please read the updated REXXGDB2.INF for more details.
4. G2SelectOne handles long characters as follows:
It now also populates a 'special REXX variable', like G2SQLCODE,
called G2LONGRESULT.
G2LONGRESULT contains REXX NULL character ('') if the value returned
is not longer than 254 characters.
Otherwise, i.e. if the (VARCHAR, LONG VARCHAR, etc.) value is longer
than 254 characters, G2LONGRESULT contains the entire string (not
truncated). The function (G2SelectOne) in this case still returns
the first (left most) 254 characters of the string.
Please read the updated REXXGDB2.INF for more details.
5. As with the previous version, this one was also created using USERID
as the owner of the (REXXGDB2) package.
If necessary, you could execute something similar to the following
SQL statement using DB2 CLP from an OS/2 command prompt to grant
users access to the REXXGDB2 functions:
===> DB2 GRANT EXECUTE ON PACKAGE USERID.REXXGDB2 TO PUBLIC
6. CUDFGDB2.ZIP containing some additional DB2/2 User-defined Functions
which can be used as scalar functions is now included as part of this
package.
------------------------------------------------------------------------
Version 1.00 Sunday, December 10th, 1995
========================================================================
1. Before running test programs, make sure that DB2/2 has been started
and/or you're connected to an active DB2/2 server.
2. All test programs are using SAMPLE database
If you're using DB2/2 2.x single user version, you can create
SAMPLE database by issuing DB2SAMPL on an OS/2 command prompt.
Otherwise, contact your DB2/2 DBA or modify the test programs
to use your test database. In the latter case, make sure that
you also change the test SQL statements so that ORG and STAFF
tables are replaced accordingly.
3. Use caution in using G2SetCurPkgSet function. The last set package-
set will still be in affect within the same process, even if you are
running another program. This could cause problems if the following
programs do not have the same collection identifier.
As an example, if you start an OS/2 command prompt and run G2FUNCS,
and upon its completion, within the same OS/2 command prompt, start
RUN-EXEC or RUN-G2, you would have a problem since DB2AR used to
load SQLEXEC and SQLDBS does not have the same collection id. last
set in G2FUNCS, which is G2GOISO. The first dynamic SQL in the
(later) program will return SQLCODE -805.
Currently, no solution is at hand to solve this problem other than
by closing the current session (using EXIT on the OS/2 command
prompt), and/or start another OS/2 command prompt to run subsequent
programs.
Again, this problem only occurs when you change the current
packageset collection identifier (using G2SetCurPkgSet).
G2Funcs shows how to use it and why it could be beneficial to
utilize this feature in some cases.
A way to avoid the above problem is to first run programs which do
not change the default packageset before those which do.
In other words, in the above example, it would be okay to first run
RUN-EXEC and/or RUN-G2 before G2Funcs. Subsequently, you could also
run G2Funcs multiple times within the same OS/2 command prompt
since G2Funcs sets the current packageset to the one that it created.
4. To get fair results, make sure you run the benchmark test programs
several times and record the best performance of each of the
programs. The first run of each of the programs may be much slower
due to program tokenization, DB2/2 connection, and functions loads.
5. Program tokenizations
To be able to produce good benchmark results, when comparing IBM
and Quercus REXX engines for OS/2, you must first understand when
the engines tokenize the REXX source codes and what they do with
the tokenized codes.
Using IBM OS/2 Procedures Language 2/REXX
- Implicit tokenization
During first program execution, or when the interpreter detects
that the source codes do not (longer) match with the (previously)
tokenized codes in the corresponding Extended Attribute file.
- Explicit tokenization
By running the program on an OS/2 command prompt and passing
parameter //t (or //T) such as: myprog //t
In this case, the program is actually not executed nor is the
parameter //t (or //T) passed to the REXX program.
- Notes
As discussed above, IBM places REXX tokenized codes in the
Extended Attribute file which can only hold up to 64 kbytes of
information. If the tokenized (textual) REXX program codes file
is larger than 64 kbytes, the tokenized codes will not be saved
which means that the tokenization will always be implicitly done
on any execution.
Using Quercus Personal/REXX for OS/2 version 3.0
- Implicit tokenization
During every program execution, when the interpreter detects that
the tokenized codes are not in the (program) file, following the
end-of-file marker.
- Explicit tokenization
By running the program on an OS/2 command prompt and passing
parameter //T such as: myprog //T, or by running PREXX30 using
parameter /O such as: PREXX30 /O myprog.
In this case, the program is actually not executed nor is the
parameter //T passed to the REXX program.
- Notes
As discussed above, Quercus places REXX tokenized codes in the
same (textual) REXX program file, following the first end-of-file
marker.
The tokenized codes are normally not visible to the programmers
as most text editors only read a file up to the end-of-file marker.
These editors will consequently also 'remove' those tokenized
codes when the REXX program is modified and saved.
This mechanism solves at least the following problems:
* Source codes are not necessary to run with Personal/REXX
* Size of the tokenized codes is only limited by disk space
On the negative side:
* Tokenized codes must be explicitly rebuilt when the source codes
are modified.
6. Tips in using dynamic SQL in REXX to access DB2/2 2.x database
- Always first set the current query optimization = 0
This minimizes the time used by the DB2/2 2.x engine to prepare
the SQL. By default, IBM sets the current query optimization = 5.
If necessary, adjust the current query optimization for some
(dynamic) SQL statements to deliver optimum response time
(i.e. total time to prepare + open cursor + (multiple) fetch(es))
- Use SQL parameter marker (?) selectively
As a rule of thumb, do not use the parameter marker in the SQL
if the prepared SQL is not going to be used more than 5 times
within the same program execution.
Instead, prepare a complete SQL statement in the REXX program and
then pass it to the DB2/2 engine (via SQLEXEC) for preparation
there. If the data in the SQL statement contains single quotes,
make sure those single quotes are repeated in the SQL string
before the SQL string is passed in the DB2/2 SQL preparation.
Example:
UPDATE EMPLOYEE SET LASTNAME = 'O'Brien' WHERE CLIENTID = 123
must first be translated into
UPDATE EMPLOYEE SET LASTNAME = 'O''Brien' WHERE CLIENTID = 123
------------------------------------------------------------------------
Thank you for considering and/or using REXXGDB2.
Simon Husin
Global Automation Co.
Kent, Washington
U.S.A.
E-mail: husin@ibm.net
Fax: 1-206-813-8202